那麼麻煩的需求，到底要怎麼解決呢？

前一陣子在網路學習平台上看到一個來自於 Functional Programming 的一個很有趣的模型

這裡就叫他為 Either 吧，寫法大概是這樣

public abstract class Either<TLeft,TRight>
{
    public abstract Either<TNewLeft, TRight> MapLeft<TNewLeft>(Func<TLeft, TNewLeft> mapping);

    public abstract Either<TLeft, TNewRight> MapRight<TNewRight>(Func<TRight, TNewRight> mapping);

    public abstract TLeft Reduce(Func<TRight, TLeft> mapping);
}

這個類別的作用類似於 Strategy Pattern

而只是他的決策只有兩個 Left or Right

但這要怎麼使用才會有二選一個效果呢

所以當然不只有這個，現在在把 Left 和 Right 都建立出來吧

    public class Left<TLeft, TRight> : Either<TLeft, TRight>
    {
        TLeft Value { get; }

        public Left(TLeft value)
        {
            this.Value  = value;
        }

        public override Either<TNewLeft, TRight> MapLeft<TNewLeft>(Func<TLeft, TNewLeft> mapping)
            => new Left<TNewLeft, TRight>(mapping(this.Value));

        public override Either<TLeft, TNewRight> MapRight<TNewRight>(Func<TRight, TNewRight> mapping)
            => new Left<TLeft, TNewRight>(this.Value);

        public override TLeft Reduce(Func<TRight, TLeft> mapping)
            => this.Value;
    }

    public class Right<TLeft, TRight> : Either<TLeft, TRight>
    {
        TRight Value { get; }

        public Right(TRight value)
        {
            this.Value = value;
        }

        public override Either<TNewLeft, TRight> MapLeft<TNewLeft>(Func<TLeft, TNewLeft> mapping)
            => new Right<TNewLeft, TRight>(this.Value);

        public override Either<TLeft, TNewRight> MapRight<TNewRight>(Func<TRight, TNewRight> mapping)
            => new Right<TLeft, TNewRight>(mapping(this.Value));

        public override TLeft Reduce(Func<TRight, TLeft> mapping)
            => mapping(this.Value);
    }

所以實際上是用建構子所帶入的參數來決定實際上被使用的類別

所以實際上的用法大概像是這樣

public abstract class MyChoose {
    public Either<LeftType, RightType> Run(object val)
    {
        if(val is RightType right)
            return new Right(right);
        else (val is LeftType left)
            return new Left(left);
        // 此處因為示範緣故，未定義空物件，所以單以名稱表示
        return Left.Empty;
    }
}

而最後回傳結果的用法是

    string result = either.MapLeft(left => left.ToString())
        .Reduce(right => right.ToString());

解釋一下為什麼這樣就可以正確取得我們所要的結果

當我們使用 Left 的時候呼叫 MapLeft 會確實讓我們帶入的參數 Left.ToString() 被執行

並且將結果成為新的 Either<string,RightType> 的建構子參數來建立新的 Either 物件

而如果呼叫 MapRight 時，只做把原本的 LeftType 放進新的 Either<LeftType,TNewRight>

並不會去呼叫參數的方法

所以這時候就會發生無論 MapRight 怎麼呼叫都不會改變實際的結果

反之 Right 也是只處理 RightType 的進展，同時忽略 Left 相關的所有方法

而最後 Reduce 則是將 Right 型別變成 Left 的型別的物件的目的是為了取得最終結果

以上述的範例，如果想要取得字串結果，那我就先把左邊變成字串

最後在 Reduce 把右邊也變成字串

那最後的結果就一定會得到字串

這好像挺接近我們想要的結果

• 可對應於各種回 傳case 的 result
  • 因為泛型的緣故，所以 Left Right 皆可以自行選擇型別，而且可以各自在成為新的 Either
• 同時也要可以提供Exception
  • 只需要讓其中一邊的型別為 Exception 即可
• 必且可以規範使用者如何使用，並使其不會自發或慣性的產生bad smell
  • 我們可以把方法名稱換成合適的名稱，那使用者就自然會知道要如何去呼叫，那使用者就會依循規範取得想要的結果
• 我想要通用版本
  • 因為為泛行而且可以持續二選一，所以任何需要選擇的狀況應該都適用

補充優點

• 這個模型因為為泛型型別，而且未使用任何的約束條件，所以每一種結果的物件皆可以完全無相依性
• 藉由泛型物件的型別持續於方法中變換，可以讓使用者自行決定最終的結果
• 由於變換型別的方法由使用者自行決定，所以使用者可以使用自己開發的方法來轉換型別
• 轉換方法的執行由提供者來決定是否執行，所以可以要如何去執行最終還是交由提供方

可能適用的方法已經有了，接下來如何將這個解決方案變成我們所期望的結果

就讓我們繼續看下去吧

備註：

• 如您目前是團隊工作，則請遵守團隊所訂下的撰寫規範，此篇文章僅為參考建議使用
• 目前大多數的解決方案，往往都一定會附加其他優勢，這是值得努力的方向
  • Dependency Injection (DI)：作為 IoC的解決方案，並且藉由 Constructor Injection 來解決複雜的建構以對應 SOLID 原則所產生的眾多小類別，而且各加 DI 提供廠商也有開發自己的特色 ex: Castle 的 Dynamic Proxy
  • Unit Test：原本單純的程式碼測試，除了反向操作後所得到新的開發模式 TDD ，並且還可藉由此衍生出 Kata，作為測驗與練習的解決方案
  • Open Source：原本最大的困境盜版與攻擊，藉由社群的力量和商業模式轉型，不僅加快了發展速度，而且更產生了容易接近與了解使用者的需求作為發展方向，這樣的良性循環
  • 我相信還有很多現代的解決方案都是這樣的，就靠各位看官發現囉
• 本篇所介紹的模型來自於 Pluralsight 中 Zoran Horvat 講師所提供的課程 Advanced Defensive Programming Techniques 的最後一節．該節也是將此模型用於 Request Result 和 Exception Handle
• 個人非常推此位講師的課程，如果對此講師的課程有興趣，可以考慮使用 Pluralsight 的免費試用，或是註冊微軟的Visual Studio Dev Essentials，裡面的 Benefit 其中一項就是 Pluralsight 的 3個月免費訂閱
• 如果你已經用完了，就辦個新帳號再來一次吧